8章 技術方式
アプリケーション全体を組み立てるために、コンポーネント同士の相互関係や依存関係をどのように構造化するかを学ぶ
業務ロジックと技術方式
システムは、ユーザー、DB、外部サービスなど様々な対象と連携が必要なため、コードベースが扱うべき関心事は多岐にわたる
なので、実装の関心事を適切に構造化できていないコードベースは、変更容易性が低くなる
業務ロジックがユーザーインターフェースやデータベースに実装されていたり、、
結果として、変更がし辛いシステムがうまれてしまう
この問題を解決・軽減するために技術方式(アーキテクチャ)を導入し、コードベースのさまざまな関心事の構造化を行い、関心ごとの境界を明確にする。
レイヤードアーキテクチャ
もっとも一般的な技術方式の1つ
以下のようにコードベースを階層構造像で整理し、レイヤーごとに異なる関心事を取り扱う
プレゼンテーション層
エンドユーザーとの対話のためのユーザーインターフェースを実装
業務ロジック層
プログラムの業務ロジックを実装しカプセル化する役割。業務上の意思決定が行われる場所
データアクセス層
永続化の仕組みと接続する機能を提供
さまざまな外部システムとの通信は個々で行う
https://scrapbox.io/files/69283d87754f0ac6b7222340.png
レイヤーを追加して拡張してもよい
サービス(アプリケーション)層
プレゼンテーション層と業務ロジック層の仲介役として、複数の業務ロジックを操作する1つのインターフェースを提供する
業務ロジックのファサードのようなイメージ
いつ使うか
業務ロジックをトランザクションスクリプトやアクティブレコードで実装するシステムに向いている
ただ、ドメインモデルを実装するのは向いていない
レイヤードアーキテクチャはトップダウン式の依存関係であるため、ドメインモデルがインフラストラクチャの知識を持ってしまうことがある
なのでその際は、ポートとアダプターを採用する
ポートとアダプター
ポートとアダプターは、業務ロジックをインフラストラクチャ層から切り離すために利用する
業務ロジックでは、インフラストラクチャ層で実装すべき「ポート」を定義し、インフラストラクチャ層ではポートの詳細実装として「アダプター」を実装する
ヘキサゴナルアーキテクチャでもこのワードが登場する
takumines.iconポートとアダプターはアーキテクチャというより、依存関係逆転の原則を適応するための手法といったイメージ
CQRS
CQRSは単純に、QueryとCommandで読み書き処理モデルを分けるという話しではない
takumines.icon一回読んでも難しかったので、また後日まとめる